Typical performance analysis, debugging, and similar tools (hereinafter referred to collectively as “tracing tools” and “monitoring” tools) allow users to visualize data that, e.g., regards one aspect of the behavior of a process. For example, suppose a user is attempting to determine why a particular application that makes use of a remote network is crashing. The user may attempt to detect memory leaks by making use of a first program. To determine whether the problem is instead related to a faulty network protocol implementation, the user must use a different tool and run the application again because the results produced by the first tool are either incompatible with the second tool, and/or because the information determined by the first tool is not easily correlated with the information produced by the second tool. Even if both tools were operated simultaneously, it is possible that they could interfere with one another, causing unreliable results.
Another problem with the aforementioned debugging process is that the user is left to guess whether the problem is the result of a combination of different aspects, such as a memory leak only critical when the network protocol implementation is incorrect.
Additionally, the user must manually and repeatedly execute the process or processes that are being traced and cause the appropriate interactions with the program to occur (such as key presses and file opening operations). If the anomaly only occurs infrequently, such as every one in ten times the application is run, or if the interactions required (e.g., multiple mouse clicks) are cumbersome, the user's attention is more likely to be focused on executing the suspect application and away from the debugging tool.
Therefore, it would be desirable to have a better way to identify anomalies.